The present invention relates generally to Common Channel Signalling Networks, and more specifically to the Signalling Connection Control Part Management Procedures.
According to the Telecommunication Standardization Sector of the International Telecommunication Union (“ITU-T”) Recommendations Q.711–Q714 for Signalling System Number 7 (“SS7”), the Signalling Connection Control Part (“SCCP”) is situated between the User Part or Application levels and the Message Transfer Part (“MTP”) levels. In this respect, a Signalling Network purely based on SS7 comprises a plurality of SS7 Nodes, generically known as Signalling Points (“SP”), that are interconnected by Signalling Links. Moreover, SS7 nodes are internally structured as a protocol stack having different levels.
Generally speaking, the MTP is in charge of the Physical level (MTP level 1), the Datalink level (MTP level 2), and the Network level (MTP level 3), in accordance to the lowest layers in the Open System Interconnection (OSI) model.
More specifically, the physical level deals with the electrical characteristics to transmit and receive SS7 message data through the links. The datalink level provides error detection and correction, as well as the means to manage, buffer, and control data transmission, and eventual retransmission, in the appropriate sequence through the links. The network level is responsible for SS7 message Routing, SS7 message Discrimination, and SS7 message Delivery functions, in which an SS7 message is generally referred to as a Message Signal Unit (“MSU”).
Nowadays, the rapidly growth of Internet applications and the needs for interconnecting the previous generation based systems with newer ones force to consider different protocol mixtures in combined stacks. In this respect, working groups like SIGTRAN under the Internet Engineering Task Force (“IETF”) are issuing different recommendations to enable transport mechanisms to transfer SS7 signalling throughout the Internet network. These transport mechanisms, described by different SIGTRAN recommendations, make use of different combinations of protocols arranged in different stacks, depending on the SS7 layer having messages to be transported. For example, some mechanisms and architectures have been introduced to encapsulate or to adapt the SCCP signalling to underlying protocol stack layers other than MTP, like the Stream Control Transmission Protocol (“SCTP”), or the Transmission Control Protocol (“TCP”), further encapsulated or adapted over the Internet Protocol (“IP”).
The SCCP, generally speaking, is in charge of functions partially comprised by the Network level and functions partially comprised by the Transport level. In other words, the SCCP provides additional functionality to the MTP Network level functions, or to other Transport level functions like the aforementioned SCTP or TCP. Moreover, SCCP supports both Connectionless and Connection-Oriented network services between SCCP Users located in SS7 Signalling Nodes, namely Signalling Points. For the purposes of this description, an SS7 Signalling Node is a network node in which at least the SS7 SCCP layer is supported. Furthermore, an SCCP of reference also comprises the SCCP network Management function that is in charge of maintaining the status of the remote signalling points, the remote SCCP layers, and the remote SCCP applications with which the SCCP of reference has a signalling relationship.
Still further, the SCCP network Management also informs its local users (also called “SCCP applications”) about changes in the states of remote signalling points and remote subsystems, namely SCCP applications, that the SCCP network Management monitors. In a similar way, the SCCP applications may inform the local SCCP about their availability for receiving traffic for the latter to appropriately inform the remote signalling points with which there is a signalling relationship.
In accordance with ITU-T recommendations Q.711–Q.714, the SCCP network Management makes use of certain standard messages and primitives. All these SCCP management messages and primitives consider the SCCP as a whole network entity layer, without distinguishing between SCCP connectionless and SCCP connection-oriented services. Also in accordance with the aforementioned recommendations, an SS7 signalling message is an information unit exchanged between SS7 nodes, whereas SS7 primitives are information units exchanged between different layers of a protocol stack in an SS7 node. In this respect, assuming that different layers might be supported by protocols other than SS7, and as already mentioned for the purposes of this description, an SS7 Signalling Node is a network node in which at least an SS7 SCCP layer is supported.
For example, the SS7 Management message Subsystem Status Allowed (“SSA”) message indicates to the receiver SCCP that the affected Subsystem Number representing an SCCP application (“SSN”) in a remote SP becomes available for signalling traffic purposes. Another example of an SS7 Management message is the Subsystem Status Prohibited (“SSP”) message that indicates to the receiver SCCP that the affected SSN in a remote SP becomes unavailable for signalling traffic purposes.
Still another example of an SS7 Management message is the SCCP/Subsystem Congestion (“SSC”) message that indicates to the receiver SCCP that the SCCP in the given remote SP has reached the indicated congestion level for signalling traffic purposes. In this respect and more specifically, an SSN=1 message represents the SCCP itself and indicates that this remote SCCP reaches the indicated availability status or congestion level.
These SS7 Management messages at the receiver SCCP node are mapped into the corresponding primitive to indicate the local SCCP users the availability status of remote applications or nodes for receiving and sending signalling traffic. For example, the SS7 Management messages above are mapped into the primitive N-STATE_indication with the appropriate parameter values. In addition, there are primitives from local SCCP users wanting remote SCCP applications or nodes to take SS7 Management related actions, like N-COORD_request for example. Still another example of primitives from local SCCP users (identified by an SSN value) is the N-STATE_request. At reception of this primitive at the SCCP indicating “User_Out_Of_Service”, the SCCP generates an SSP Management message with the originating SCCP user SSN value as the “Affected SSN”, and the own Signalling Point code as the “Affected SP”. Similarly, at reception of this primitive at the SCCP indicating “User_In_Service”, the SCCP generates an SSA Management message with the originating SCCP user SSN value as the “Affected SSN”, and the own Signalling Point code as the “Affected SP”.
The huge market growth of mobile subscriptions makes the control and performance of mobile networks a great challenge. The mobile networks, especially, have to be carefully dimensioned to squeeze the most out of their possibilities. Quite a few mechanisms have been introduced to optimize network performance, and since most mobile networks use SS7 SCCP, the already standardized Congestion Control functionality is one of them. The Congestion Control is found to be quite significant to prioritize the most urgent signalling messages depending on the congestion level that certain SS7 nodes reach.
More specifically, quite sophisticated mechanisms can be described to assess the local nodal congestion level or local SCCP user congestion level, which are supposed to be implementation dependent by ITU-T recommendations Q.711–Q.714. However, the standard recommendations define how to indicate the congestion level to remote signalling points with which a signalling relationship at SCCP layer exist by SSC signalling messages. Moreover, an SCCP layer at an SS7 signalling node receiving such an SSC with an indicated congestion level should be able to stop signalling traffic toward the indicated affected node for all signalling messages with lower priority than the indicated for the congestion level. The aim is to reduce traffic load based on different message priorities and depending on the particular congestion level.
In this respect, the ITU-T Q.174 recommendation states that an SCCP entity is responsible for the reduction of the traffic toward a congested node by discarding a portion of the concerned traffic to be sent toward the congested node. The following parameters are used in this traffic limitation mechanism: a) the Importance Value (“IV”), b) the Restriction Level (“RL”), c) the Restriction Sublevel per RL (“RSL”), and the SCCP Congestion Level.
The IV parameter is selected by the SCCP application or by the SCCP itself in some cases (e.g., the message is originated in SCCP). As a guideline, those messages that contribute to increase the signalling traffic afterwards (e.g., CR message) shall be given less importance, that is, less priority than those messages which announce the end of a connection or transaction (e.g., the CO message RLSD). The interested reader is directed to the ITU-T Q.714 recommendation, where there are importance guidance values for the different SCCP message types (see Table 2/Q.714—Default and maximum importance value).
The RL parameter is maintained by SCCP and it is associated with the congestion level of a remote SCCP node. The RL parameter is due to the receipt of a primitive from the underlying protocol stack layers indicating congestion in the given affected SP. Provided that the underlying protocol stack layers correspond to MTP, the primitive is an MTP-STATUS_indication, otherwise the primitive is another primitive of the underlying protocol stack layers adequate to indicate congestion in a given affected signalling node.
The RSL parameter is also maintained by SCCP and it is associated with the congestion level of a remote SCCP node as well. The RSL parameter is due to the receipt of a primitive from the underlying protocol stack layers indicating congestion in the given affected SP, and the RSL applies per specific value of the aforementioned RL parameter. Provided that the underlying protocol stack layers correspond to MTP, the primitive is an MTP-STATUS_indication, otherwise the primitive is another primitive of the underlying protocol stack layers adequate to indicate congestion in a given affected signalling node.
The SCCP Congestion Level is another parameter maintained by SCCP and it is also associated with the congestion level of a remote SCCP node. The Congestion Level parameter is received in an “SCCP/Subsystem Congestion” management message for each affected SCCP. This parameter conveys the nodal or SCCP congestion of a signalling node which calculation depends on the specific implementation.
Therefore, each SCCP node maintains the congestion level of each adjacent node with the variables above. Whenever a message, either relayed from another node or locally originated, has to be sent toward its destination, SCCP performs the traffic limitation on the outgoing traffic by a comparison of the Importance Value of the message and the associated congestion level (RL and RSL variables).
In this respect, if the importance of the message (IV) is greater that the restriction level of the remote SCCP node (RL), then the message is sent and a primitive MTP-TRANSFER_request, or another adequate primitive provided that the underlying protocol stack layers are other than the MTP, is invoked. But if the importance of the message (IV) is lower than the restriction level of the remote SCCP node (RL), then the message is discarded. If the importance of the message (IV) is equal to the restriction level of the remote SCCP node (RL), then the message is discarded proportionately as determined by the restriction sublevel value (RSL). The proportion of traffic reduction is considered to be network specific and an object of administration.
All messages and primitives related to the SCCP Management function consider the SCCP (SSN=1) as a whole and the SCCP users or applications (SSN value other than 1) as users of the SCCP without other distinction. However, SCCP offers two different protocol services: Connection-Oriented and Connectionless services. In this respect, most of the currently existing mechanisms to control network congestion regarding SS7 resources do not differentiate both services, aligned with the current ITU-T recommendations.
For instance, U.S. Pat. No. 6,038,218 to Otsuka et al. teaches a method for controlling congestion on signalling links and an apparatus for controlling traffic congestion on signalling links. To this end, a plurality of signal processors is provided to accommodate shares of signalling links. Then, a congestion condition level is determined by comparing overload conditions and number of processed signals with respective threshold values. Signalling links are given certain priority, and when this priority is lower than the one corresponding to the one for the congestion condition level, such a signalling link is inhibited for use and a new signalling link from another signal processor substitutes the inhibited signalling link. Additional features are provided to clear or raise the congestion condition level.
It can be seen from this patent that there are important needs to control congestion on signalling links on which both connectionless and connection-oriented signalling traffic are involved without distinction. Provided that signalling links become congested, neither connectionless nor connection-oriented traffic can offer acceptable performance.
Nevertheless, there are quite a few other reasons apart from links that may make an SS7 Node reach a risky availability level. For example, certain SCCP applications, generally referred to as SSNs, may become unavailable due to different reasons, and thus these are reported to adjacent SS7 Nodes by SCCP Management messages.
The fact that certain SSNs become unavailable does not necessarily mean that other SSNs in the same SS7 Node are affected. However, it may occur that the SS7 Node itself, namely the corresponding Signalling Point (SP), becomes unavailable as well. This situation implies that all the SSNs in such a node will become unavailable as well, irrespective of their previous particular availability status.
In this respect, U.S. Pat. No. 5,268,895 to Topper describes an SS7 Network with Signalling Points (SP) interconnected, each of them comprising controllers of remote Signalling Points (SP) and remote Subsystems (SSN) related Management information. The patent proposes a Composite status information handled by these controllers and further used for routing of signalling traffic. The composite status further comprises the state of remote subsystems and remote signalling points in terms of individual availability status and congestion level. The patent teaches a method to handle the composite status and to use it for routing. Nevertheless, there is no approach, description, or embodiment of these method and means for to show a distinction on composite status on a per SCCP service, namely connection-oriented or connectionless service.
In the past, and nowadays to some extent, there were not many SS7 applications making use simultaneously of both Connection-oriented and Connectionless services. Just very few instances like the mobile network entity Mobile Switching Center, either alone or collocated with a Visitor Location Register (for the purposes of this application, an “MSC/VLR”), make use of both of them. As a consequence, all the SCCP Management messages could just refer to SCCP, or to SCCP applications, as a whole without distinction on whether the availability, or the congestion, or unavailability was due to Connection-Oriented or Connectionless resources. Most of the network nodes either made use of Connection-Oriented service or made use of the connectionless services. Thus, when an SCCP Management message was received indicating availability (SSA message), or unavailability (SSP message), or congestion (SSC message with indicated congestion level) from another SCCP layer in another node, the SCCP Management message simply meant that the affected SSN or SP was available, or unavailable, or congested for the SCCP service that both network nodes were sharing, irrespective of whether the services were Connection-Oriented or Connectionless.
Under this assumption, U.S. Pat. No. 5,541,987 to Topper et al. proposed a connection-oriented controller for controlling the resource availability of connections already established. More specifically, the connections are blocked when the resource availability is lower than the start-of-blocking threshold, and unblocked when the resource availability is higher than the end-of-blocking threshold. This patent further describes a method of controlling the congestion on already established connections by making use of this controller.
This patent, however, does not mention how the connection-oriented service can be distinguished from the connectionless service, or in other words, how can an SS7 network node know whether a congestion level received relates to the connection-oriented service rather than connectionless, vice versa, or both. In this respect, the only possible assessment is related to local nodal congestion, since one SS7 Node under reference might notice its own local availability, or unavailability, or congestion. However, even this local status can hardly be known unless SS7 Management primitives so indicate between layers, which is far from the explanation in this patent or in the ITU-T recommendations Q.711–Q.714.
In accordance with the ITU-T recommendations, any local application of an SCCP of reference subscribes itself to SCCP connectionless or SCCP connection-oriented services. Either SCCP service, even both of them, can be subscribed by certain SCCP applications or SCCP users represented by the corresponding SSN. Whenever any of these SSNs changes its availability status, it issues an N-STATE primitive toward SCCP which in turn prepares and sends the corresponding SSA message for an available SSN, or the corresponding SSP message for an unavailable SSN, toward adjacent SPs with an SCCP signalling relationship. Nevertheless, these management messages, as stated by ITU-T specifications, apply only on a per SCCP basis rather than applying on a per differentiated protocol service basis, namely per connectionless or per connection-oriented service.
Even though any SCCP user may subscribe to both protocol services, connectionless and connection-oriented, and be identified by a unique Subsystem number (SSN), the resources, features, and controls used under both services are not necessarily the same. In fact, they are more commonly different and separate from each other.
Moreover, the congestion control mechanisms, as stated by ITU-T and generally spread worldwide, do not differentiate connectionless or connection-oriented availability or congestion levels. Thus, a simple lack of resources for one of these two services will necessarily affect the other service since there is no broadcast mechanism or procedure to inform other adjacent nodes about the actually affected resources, but just to indicate SCCP congestion with the worst congestion level detected.
Under these assumptions, any change of availability status affecting just one of these two protocol services will certainly affect both of them since there is no possibility yet to separate such management procedures for connectionless and connection-oriented services.
In this respect, distinguishing the management procedures for connectionless and for connection-oriented services, for users as well as for the protocol services themselves, is an important object of this application.
Another object of this application is to maintain this distinction between management procedures for connectionless and for connection-oriented services in a signalling node of reference even though all signalling nodes adjacent to the node of reference are not able to make such a distinction.